The present invention relates to the field of workflow transaction processing in computer systems. More particularly, the invention relates to hierarchical transactions and compensation in computer systems.
Workflow applications are related to businesses, governments, and other organizations where information and work product flows between various persons or departments. Workflow generally is the flow of information and control in such organizations. In a business setting, workflow processes include sales and order processing, purchasing tasks, inventory control and management, manufacturing and production control, shipping and receiving, accounts payable, and the like. Businesses continually strive to define, document, and streamline such processes in order to effectively compete.
Computer systems and associated software now provide tools with which businesses and other organizations can improve workflow. Software tools may be used to model business workflow processes or schedules and identify inefficiencies and possible improvements. In addition, where a process involves exchanging data between people, departments, plants, or even between separate companies, computer systems and networks can be used to implement such exchanges. These systems and software tools are further able to implement large-scale computations and other data or information processing which typically are associated with business related information. Automation of such information processing has led to many efficiency improvements in the modern business world; and workflow management includes effective management of information flow and control in an organization""s business processes. Automation of workflow management is now allowing businesses and other organizations to further improve performance by executing workflow transactions in computer systems, including global computer networks, such as the Internet.
Many applications for workflow tools are internal to a business or organization. With the advent of networked computers having modems or other type communications links, computer systems at remote locations can now communicate easily with one another. Such enhanced communication allow computer system workflow applications to be used between remote facilities within a company. An example includes forwarding a customer order from a corporate headquarters to a remote field sales office for verification by an appropriate sales person, and returning a verification to the headquarters. Workflow applications also can be of particular utility in processing business transactions between different companies. In a typical application, two companies having a buyer-seller relationship may desire to automate generation and processing of purchase orders, product shipments, billing, and collections. Automating such processes can result in significant efficiency improvements which are not otherwise possible. However, this inter-company application of workflow technology requires co-operation of the companies and proper interfacing of the individual company""s existing computer systems.
Thus far, workflow application tools have been developed which provide some capability for automating business workflow by defining workflow applications. Many business transactions are of a short duration. For example, a buyer may wish to transmit a purchase order number along with a list of products being purchased to a seller, and the seller may wish to respond with a confirmation of the order and an expected shipment date. This type of transaction may involve a general consumer purchasing products from a retailer, or alternatively two large corporate entities which do business regularly. The data associated with the order and the confirmation may be relatively small and the transmission time for the data may be on the order of fractions of a second. A workflow application running in a computer system may allocate system resources to the transaction during its pendency, which is generally very shortxe2x80x94i.e. has a small latency. In this scenario, the system would use a conventional database transaction, i.e. an ACID transaction. An ACID transaction locks database information for the duration of the transaction. However, there are other types of business workflow transactions which have significantly longer durations and which may occupy system resources for an unacceptably long time. Such transactions often are called long running transactions.
Examples of long running transactions may include manufacturing or production control systems wherein a product is manufactured according to a particular workflow. It is common for a product to be manufactured in separate subassemblies, possibly at remote facilities. In such a situation, the time between production initiation and completion may be days, weeks or even months. A workflow application which tracks or manages progress of such workflow may be resident in a computer system for a very long time. Moreover, the application may wait several weeks for the product to reach an intermediate assembly stage, perform some bookkeeping function which lasts for several seconds, and then remain waiting again for several days for the next production stage. Such long running transactions may occupy system resources for unacceptable periods of time, while performing a relatively small amount of work. Consequently, there remains a need for workflow application tools which can execute long running transactions in a computer system, while utilizing system resources judiciously.
System resources in this regard, may include allocated space in memory for executable code and associated data, as well as permissive access to databases. In order to maintain data coherency, access to certain elements of data may be restricted to (exclusively allocated to), a specific instance of a workflow transaction until the transaction completes, (e.g., aborts or commits). Access to these data elements is denied to other transactions or objects while the transaction of interest is active. Once a running transaction successfully completes, or commits, the data is unlocked (e.g. becomes available for access by other transactions or programs). On the other hand, if the transaction fails or aborts, a transaction log is consulted and data manipulations performed by the aborted transaction are undone, (e.g., rolled back).
Heretofore, transaction commit rules and roll-back methods have been provided in order to ensure ACID properties of transactions. Transactions have conventionally been thought of as collections or groupings of operations on physical and abstract application states. ACID properties include atomicity, consistency, isolation, and durability.
Atomicity refers to a transaction""s change to a state of an overall system happening all at once or not at all. Consistency refers to a transaction being a correct transformation of the system state, and essentially means that the transaction is a correct program. Although transactions execute concurrently, isolation ensures that transactions appear to execute before or after another transaction, because intermediate states of transactions are not visible to other transactions until the transaction commits (e.g., the data is locked during execution). Durability refers to once a transaction completes successfully (commits), its activities or its changes to the state become permanent and survive failures.
In conventional transaction processing systems and methods, an application program starts a new transaction, and thereafter, the operations performed by the program are part of the transaction until the transaction commits or aborts, including all operations performed by other programs on behalf of the transaction. If no failures occur, the program informs the outside world that the transaction is a complete and correct transformation by committing. Otherwise, the transaction aborts and data manipulations, messages, etc. are undone by roll-back procedures. To an outsider, the transaction appears to be atomic, because the transaction either commits (its changes to the data have been made), or it aborts (no changes have been made, or the changes have been rolled-back). The atomicity property is thus assured through the commit protocol of the transaction and through the roll-back procedure.
With regard to the isolation property, conventional systems and methods implement a commit rule, whereby access to data associated with an action within a root transaction is restricted to the action until the root transaction commits or aborts. Only when the root transaction has either committed (thus assuring validity and coherency of data associated with one of its component actions), or aborted (thus assuring that invalid or incoherent data manipulations, messages, etc., have been undone), is the data unlocked, thereby allowing access to other programs and actions. Thus, the commit/roll-back protocols and procedures, together with data locking implementation, have heretofore enabled the isolation property.
For long running transactions, data locking may be undesirable, since other actions or programs may be prevented from running due to the unavailability of data access, (e.g., the data needed by the actions has been locked). For example, accounting transactions may be prevented from accessing an inventory database to query inventory of a product subassembly because a long running production control transaction has exclusive access to this data during tracking or managing production of certain units of manufacture which include the subassembly. Locking database resources for significant durations reduces system scalability. In addition to restricting data access with respect to other programs, actions, etc., prior art systems and commit rules effectively restrict data access by monitoring tools, such as database query tools. This has heretofore prevented fine-grained monitoring of schedule status.
Furthermore, there exist situations where conventional commit rules and rollback techniques cause operational inefficiencies. Where a transaction includes a large number of actions which execute sequentially, the last action may fail after previous actions have successfully completed. Conventional roll-back methods typically require that all work done by successful actions be undone, after which the transaction containing the many actions is aborted. Rolling back work of all prior transactions may itself involve a large amount of work, and require allocation of system resources. Moreover, some work that is being rolled back may have been valid, and may not need to be redone.
Prior attempts at nesting transactions within transactions ensured ACID properties through a commit rule wherein the results (e.g., data, messages, etc.) associated with a completed sub-transaction are accessible only to a root or ultimate parent transaction until the root or ultimate parent transaction itself commits or aborts. Under this conventional rule, the sub-transaction will finally commit (e.g., release its results to the outside world) only if it has completed successfully, and all its ancestor transactions up to the ultimate parent or xe2x80x9crootxe2x80x9d transaction have committed. Consequently, data associated with a sub-transaction becomes accessible to the world only if the sub-transaction""s ultimate parent or xe2x80x9crootxe2x80x9d transaction has committed or aborted.
According to the present invention, transaction boundaries of a schedule are defined by a user, and a run-time system executes the schedule. As used herein, the term schedule means an application, which may comprise, for example, a workflow application. A graphical user interface or a schedule definition language may be used to define groups or sets of component actions within a schedule. Transaction boundaries are determined based on the transactional scope of the groupings. Transactions may include sub-transactions. Hierarchical relationships may be formed between transactions within a schedule. The schedule may thus comprise hierarchical transactions, which may be compensated according to various aspects of the invention. The defined schedule can subsequently be bound onto specific technologies using binding tools. Instances of the schedule list are then created for execution. A run-time engine according to the invention stores a schedule state at transaction boundaries, allowing fine granularity for users to perform schedule-monitoring functions, and improve system error recovery. In addition, the invention provides a method of committing hierarchical transactions which allows a user to allow access to data based on the user-defined transaction boundaries of the schedule. The invention includes a method and a system for executing a schedule in a computer system, as well as a computer-readable medium having computer-executable instructions for performing the steps of the inventive methods.
According to one aspect of the invention, a method for executing a hierarchical transaction having a parent transaction and a sub-transaction is provided. The method comprises executing an action (or a set of actions) associated with the sub-transaction and committing the sub-transaction upon successful completion of the actions associated therewith, thereby allowing access to data associated with the actions according to a transaction boundary associated with the sub-transaction. The method provides selective restriction of access to the data associated with an action (or a set of actions) in the schedule according to at least one user-defined transaction boundary and the state of the actions. The method thus allows an action""s associated data to be unlocked as soon as its immediate hierarchical parent transaction commits. Access is then allowed to other objects, programs, etc. even though the parent transaction may be a component inside another hierarchical transaction.
The invention further includes a method and system for selectively compensating at least one action according to a compensation parameter and at least one transaction boundary after abortion of another action. This selective compensation allows a user to relax the conventional isolation property through the above mentioned selective data access restrictions, while providing a method for maintaining data validity and coherency on an as-needed basis.
Another aspect of the invention includes a method and system for storing schedule state information to a storage medium based on a transaction boundary within the schedule. In addition, the invention provides for selectively obtaining at least a portion of the schedule state information from the storage medium, and selectively monitoring the schedule execution based on at least a portion of the schedule information obtained therefrom. The current state of the schedule can be determined, either by queries to the storage medium holding the stored schedule states (history reporting), or by monitoring the data stream being stored as transaction boundaries are encountered (event monitoring). Allowing the user to so define the logical transaction boundaries in the schedule definition, therefore allows fine-grained access to schedule status information with the capability of generating and analyzing history reports for the schedule execution. Further provided, is a computer-readable medium having computer-executable instructions for performing the steps of the above methods.
In accordance with one aspect of the invention, a method is provided for executing a schedule, which comprises a schedule state (e.g., the current state of the schedule) and a plurality of transactions. The transactions may include a transaction boundary, a transaction state, and at least one action having an action state and data associated therewith. The method includes executing the actions according to the schedule, and committing the transaction upon successful completion of an action associated therewith, according to at least one transaction boundary associated with the action and the action state.
In accordance with another aspect of the invention, a computer-readable medium is provided having computer-executable instructions for executing a schedule which has a schedule state and a plurality of transactions. The transactions may include a transaction boundary, a transaction state, and at least one action having an action state and data associated therewith. The computer-readable medium has computer-executable instructions for executing the actions according to the schedule, and committing at least one transaction upon successful completion of an action associated therewith.